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Field of the Invention 

The invention relates to electronic communications, and more particularly to 
authenticating the identity of network users. 

Background of the Invention 

A variety of networks are used today. Computer networks include local area networks 
(LANs), metropolitan area networks (MANs), wide area networks (WANs), intranets, the 
Internet and other types of networks. Communication networks include those for 
conventional telephone sendee, cellular networks of different varieties, paging services and 
others. Networks are used for many purposes, including to communicate, to access data and 
to execute transactions. For many reasons, including security, it is often necessary to confirm 
or authenticate the identity of a user before permitting access to data or a transaction to occur 


on the network. 


One known approach to computer network authentication is the use of user-specific 
passwords. Passwords provide some level of protection, but they are not fail-safe. One 
reason passwords are vulnerable is that users often share them. Even if they are kept private, 
someone who wants to obtain a password badly enough often can, using random generators, 
keyboard monitors or other techniques. Moreover, when dealing with unknown users such as ' 
people who want to conduct an electronic transaction over the Internet, ad hoc passwords are 
not practical. 

Various non-password schemes exist that perform some level of authentication before 
authorizing transactions or permitting access to data. These systems generally require a user 
to provide a sampling of basic identification information such as name, date of birth, social 
security number, address, telephone number and driver’s license information. This sort of 
information, sometimes known as wallet-type information, is compared to known data such 
as a credit file to determine how well the user’s input matches that source. 

For various reasons, one-level authentication schemes are not totally reliable. In some 
instances, a user who provides accurate identification information may not be authenticated. 
This may occur, for example, because the user enters a nickname or a contraction rather than 
a proper name, and the authentication process does not check for a nickname or other 
variation. As a result, a user who should be entitled to access information or perform a 
transaction can not. Other inconsistencies may trigger a false negative, and often the false 
negative will terminate the transaction without further processing or corrective querying. 

In other instances, a user who supplies fraudulent information may be authenticated. 
This may occur when lost or stolen wallet-type information is entered by an unauthorized 
user. Other situations may also lead to a false positive result. Both false positives and false 


negatives are undesirable. 
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Other reasons for unwarranted summary rejection, and other drawbacks, exist. 


Summary of the Invention 

An object of the invention is to overcome these and other drawbacks of existing 
authentication systems and methods. 

Another object of the invention is to provide an authentication system and method that 
perform a first level of authentication based on a first type of information and, based on the 
results of the first level of authentication, determine whether to perform at least a second level 
of authentication using another type of information. 

Another object of the invention is to provide an authentication system and method that 
determine whether to perform at least a second level of authentication depending on available 

information and the level of certainty desired. 

Another object of the invention is to provide an authentication system and method 

including an automatic interactive queiy feature. 

Another object of the invention is to provide an authentication system and method 
which preprocess information supplied by the user to check, for example, the standardization, 
format, validity and internal consistency of that information before comparing it to known 
data. 

Another object of the invention is to provide an authentication system and method 
which are customizable. 

Another object of the invention is to provide an authentication system and method that 
access information from a variety of data sources. 
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Another object of the invention is to provide an authentication system and method that 
allow selection of data sources used for comparison, and the circumstances under which those 

comparisons are made. 

Another object of the invention is to provide an authentication system and method that 
generate a score indicating the confidence or certainty level of authentication. 

Another object of the invention is to provide an authentication system and method m 
which a minimum score or requirement may be set for particular data fields or sources. 

In an illustrative embodiment of the invention, a user who wishes to apply for an 
online transaction accesses a client/server network through a client terminal. The server side 
of the network includes an application server communicating with an authentication server. 
When the user wishes to initiate the transaction or at other times, the authentication server 
determines whether the user’s identity can be confirmed, and the level of authentication that 
may be accorded to the user’s identity based on rules specific to the vendor accepting the 

transaction. 

The transaction the user is applying for, such as an electronic brokerage trade, is either 
carried out or not carried out or other action taken depending on the results of the 
authentication. The extent of authentication processing performed depends upon the nature of 
the transaction and vendor-specific requirements. Once the authentication process has been 
satisfied, the invention may generate a digital certificate recording authentication levels and 
other information related to the user. The digital certificate can then be presented in future 
transactions to avoid the need to reauthenticate the user for each new transaction event. 

For example, in the context of electronic commerce, lower risk transactions such as 
relatively small purchases may not require an extensive authentication process. On the other 

hand more sensitive or greater risk transactions such as large purchases or sensitive data 
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access may require a more thorough authentication process and a greater level of certainty. A 
greater level of security could conceivably be attained by automatically performing a 
thorough authentication process for every transaction. However, this approach incurs 
unnecessary costs or resources in cases where only a lower level of certainty is needed. 

The invention avoids this drawback by enabling different levels of authentication to' 
be performed based on the level of security desired, reducing costs and unnecessary use of 
system resources. 

Generally in the invention, the user is authenticated according to their ability to 
respond to successive queries for personal information and the level of match attained from 
comparing the information they provide with reliable data sources. The user is initially 
requested to provide a first type of identification information. The first type of information is 
preferably wallet-type information, that is, information such as name, address, driver’s license 
or other information that may be commonly carried on the person. This information is 
transmitted to the authentication server which carries out a first level authentication process 
on that information. 

That first level authentication process compares the degree of match between the user- 
supplied first type of information and known data about the user from other sources. At the 
completion of this first level authentication process, the authentication server may allow the 
requested access, allow the requested access with restriction, refuse access or proceed to 
another level of authentication. 

Preferably, the second and any additional levels of authentication request a second, 
non-wallet type of information from the user. The second type of information is preferably 
based on comparatively private information that only the user would know. For example, the 
second type of information may include mortgage loan or other information obtained from a 


credit report or another source. Such information is typically not carried with a person, and 
therefore the chances of fraud by someone who obtains lost or stolen information and 
attempts to execute a transaction are reduced. 

The private financial or other data elicited in the second level authentication process 
may be requested using an interactive query. The interactive query may include multiple 
choice questions that are automatically generated based upon the information available in the 
known data sources. For example, the authentication server may access a credit file to 
identify loans of the user which are still in payback status. One or more loans may be 
selected and the lender’s name and corresponding monthly payment amount retrieved from 
the credit file. 

The interactive query might ask the user for the lender’s name or payment amount on 
the identified loan and offer a number of choices for each of the lender’s name and the correct 
payment amount, only one of which is correct. Depending upon the responses, the user’s 
identity may be authenticated fully, or to a greater or lower degree of certainty compared with 
that based solely on the first level authentication process. 

The invention may include a preprocessing stage executed before first or second level 
authentication. The preprocessing stage filters or corrects relatively minor mistakes in 
formatting and consistency in the user’s responses, preserving the transaction for further 
processing and avoiding needless termination before the upper stages are reached. 

Brief Description of the Drawings 

Fig. 1 is a flowchart of an overall process for authenticating users according to the 


invention. 
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Fig. 2 is a flowchart of an overall processing flow for authenticating users according 
to the invention in another aspect. 

Fig. 3 is a flowchart of certain aspects of second level authentication according to the 
invention. 

Fig. 4 is a flowchart of a preprocessing process according to the invention. 

Fig. 5 is a flowchart depicting a format verification process according to the 
invention. 

Fig. 6 is a flowchart depicting a standardization process according to the invention. 

Fig. 7 is a flowchart depicting a validity verification process according to the 
invention. 

Fig. 8 is a flowchart depicting a consistency verification process according to the 
invention. 

Fig. 9 illustrates an example of a verification matrix used in the invention. 

Fig. 10 illustrates an example of error codes that may be generated according to the 
invention. 

Fig. 1 1 illustrates an example of a preprocessing matrix used in the invention. 

Fig. 12 illustrates a block diagram of an overall system according to the invention. 

Figs. 13-16 illustrate a transaction record generated according to the invention. 

Figs. 17 and 18 illustrate pattern recognition criteria used by the invention to detect 
irregularities. 

Fig. 19 illustrates potential action taken by the invention upon detection of pattern 
recognition criteria. 

Fig. 20 illustrates a scoring matrix for different types of accounts in second level 
authentication according to the invention. 
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Fig. 21 illustrates a relative weighting of different types of queries used in second 

level authentication according to the invention. 

Fig. 22 illustrates a tiering of certainty scores into a set of categories according to the 

invention. 

Figs. 23-28 illustrate an assignment of overall certainty scores from first and second 
level authentication results generated according to the invention, from highest to lowest. 

Fig. 29 illustrates a tiering of authentication results for different types of source 
accounts according to the invention. 

Fig. 30 illustrates action thresholds for a set of different actions according to the 
invention. 

Figs. 31-33 illustrate preprocessing and first level authentication queries in an 

example authentication session according to the invention. 

Figs. 34-36 illustrate second level authentication queries in an example authentication 

session according to the invention. 

Figs. 37-40 illustrate queries used to issue a digital certificate according to the 
invention. 

Fig. 41 illustrates a digital certificate generated according to the invention. 

Fig. 42 illustrates a remote authentication system according to the invention in which 

authentication is performed in an offline fashion. 

Fig. 43 illustrates the offline remote authentication embodiment of the invention 

operating when a social security number data field is supplied. 

Pig 44 illustrates the offline remote authentication embodiment of the invention 

operating when a social security field is not supplied. 
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Fig. 45 illustrates a block diagram of an overall system according to the invention, in 


another aspect. 


Detailed Description of Preferred Embodiments 
The invention in general operates in a network environment and provides a system ' 
and method to authenticate a network user’s identity using a hierarchy of information queries. 
The invention may draw on information from one or more data sources to execute the 
hierarchy of authentication stages, depending upon the transaction or data sensitivity. The 
invention may dynamically adjust the extent of authentication necessary, based upon preset 
thresholds or upon tests of input validity as the user supplies that information. 

A front-end preprocessing stage may serve to filter or correct erroneous information 
such as mistaken zip codes, missing digits or other matters of form so that the transaction 
may be preserved without needless termination before first or second level authentication. At 
the conclusion of the authentication process, the invention may issue a digital certificate to 
the user’s machine to record authentication information, to present for later transactions or to 
update. An illustration of the overall architecture of the invention is in Fig. 45, and 
flowcharts of the overall processing flow are shown in Figs. 1 and 2. 

In terms of the network environment of the invention, in an embodiment illustrated in 
Fig. 12, client 110 communicates with application server 130 over a physical or wireless 
transmission link 150. Transmission link 150 may be a direct Internet connection or include 
the Internet as an intermediate segment. Transmission link 150 may include a dial-up 
Internet connection, dial-in server access, an intranet connection, a T 1 or T3 digital line, an 
ISDN digital line, LAN connection, a wide area network, Ethernet, DSL connection or other 


wired or wireless connection. 
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In an Internet context, application server 130 preferably contains Internet server 
software (such as the publicly available Apache package or others) communicating with a 
browser application resident on client 110, which may be a personal computer or workstation 
running the Microsoft Windows™ 95 or 98 operating systems, Internet access device such as 
a WebTV™ unit, or other hardware or software. 

The system includes an authentication server 120 on which the authentication process 
10 of the invention is resident and executes. Authentication process 10 may be for instance 
implemented in programmed machine instructions, such as in C, C++, Java or other 
compiled, interpreted or other computer programming languages. In an alternative 
embodiment, authentication process 10 may be coresident on application server 130, 
obviating the need for authentication server 120. Authentication server 120 and application 
server 130 each may each be a workstation or personal computer, for instance running the 
Unix, Linux or Microsoft Windows™ NT™ operating systems or other hardware and 
software, and each may communicate with various databases to obtain user identification 
information for first and second level authentication. 

As illustrated in Fig. 12, such databases may include a credit database 160, mail 
database 170, phone database 1 80 and one or more other databases 190 which may be directly 
or indirectly accessible by or resident on authentication server 120 or application server 130. 
In addition, authorization database 152 is associated and communicates with authentication 
server 120. Authentication process 10 preferably receives and stores data to and from the 
authorization database 152, including transaction record 1 12 (illustrated in Figs. 13-16) which 
logs user input, queries and other information as a temporary or permanent record. 

Fig. 12 also shows one or more resources 140 which are accessible to application 

server 130. These may include, for example, databases, other computers, electronic memory, 
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CD ROMs, RAID storage, tape or other archival storage, routers, terminals, and other 
peripherals and resources. 

According to the invention, a user who wants to access information or process a 
transaction over a network is prompted to submit information to authentication process 10 
through client 110. Authentication process 10 invokes the preprocessing step 26, in which - 
the user is prompted to supply a first type of user identification information. The first type of 
user identification information preferably comprises wallet-type information such as name, 
address, phone number, social security number, driver’s license number and other common 
personal information. 

This information is supplied to authentication process 10 via application server 130, in 
a standard application format, by client 110. In one aspect of the invention, application server 
130 may be operated by an online vendor, such as a brokerage firm, merchandise retailer or 
other (see e.g. Fig. 45) and serves as a conduit between client 110 and authentication server 
120 once authentication process 10 is invoked. It is possible however for client 110 and 
authentication server 120 to communicate the requested data directly without passing through 
application server 130. 

The user inputs the first type of information requested into client 110. Data may be 
queried from the user through textual questions, graphical user interfaces (GUIs), hyper text 
markup (HTML) forms or any other suitable mechanisms, either in a real-time interactive 
environment or thr ough a batch submission. Selection of the input mode may depend upon 
various factors such as resource loading and availability, business model, user and system 
traffic and transaction criticality. 

Following the initialization of the transaction record 112, the association check 24 

may be executed. Before entering the preprocessing step 26, the authentication process may 
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invoke association check 24 to evaluate whether the request under consideration is associated 
with other requests or attempts, whether recent, concurrent or otherwise. The purpose of the 
association checks is to filter requests suspected to be fraudulent or part of an attack of some 
kind. Pattern recognition (illustrated in Figs. 17 and 18) may be used to identify requests 
which should be identified as having a fatal defect or potential for fraud, requiring immediate 
rejection of the request. 

In a preferred embodiment, authentication process 10 stores information received 
through all requests in the authorization database 152, which stores transaction record 112 
logging all input received from the user. Using this information, association checks based 
upon available data are facilitated. For example, if one attempt at access includes a name and 
an associated social security number, a concurrent or later request with the same name but a 
different social security number may be denied or flagged for further authentication. 

Conversely, if the later request includes a different name but the previously submitted 
social security number, the request may also be denied or flagged for further authentication. 
Association checks can examine any data provided by the user before or during the 
preprocessing step 26. 

After association check 24, the preprocessing step 26 may occur at one or more of 
authentication client 110, authentication server 120 and application server 130. 
Preprocessing step 26 at client 110 may be effected through the use of, for example, the 
transmission of Java applets to client 110 or through other software resident or executing on 
client 110. Thus, although authentication process 10 is shown in Fig. 12 to be resident on 
authentication server 120, portions or all of authentication process 10 may be distributed 


elsewhere. 
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One advantage of the preprocessing step 26 is that it processes as much of the 
requested data as possible before retrieving data from separately stored data sources such as 
credit files, which can be expensive in terms of processing resources, time and cost. Those 
separate data files may be accessible via the Internet or other networks, may be owned by 
separate entities and may involve a per-access charge. The preprocessing step 26 involves in 
one regard assuring that data formatting is consistent between the information supplied by the 
user and what is expected in the databases. 

Preprocessing step 26 thus helps to ensure that the supplied data is as accurate as 
possible to increase the likelihood of generating a match when the user’s identity is genuine. 
This reduces false negatives due to inconsistencies such as supplied nicknames instead of a 
full first name, contractions, missing titles, or mismatched formatting of social security 
numbers applied against known data sources. 

If the data supplied by the user is determined to be not feasible, incorrect, or otherwise 
clearly deficient before soliciting data from the separate data sources, it is still possible to 
proceed to those other data sources after the user input has been revised to meet the minimum 
requirements without interrupting the overall transaction. 

If the user does not respond to a request for a mandatory item of information ( e.g ., 
name) it is preferable to reprompt the user for that field before incurring any database charges 
or expending additional processing resources. Another example where interception in this 
manner is beneficial is when a user supplies a six digit social security number. In this case it 
is clear that the response is deficient and no match is possible in the social security number 
databases, so those databases should not be unnecessarily accessed. 

In a preferred embodiment, the preprocessing step 26 may perform one or more of the 


following validation checks 
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1) Standard Field Checks . To ascertain whether all required information fields 
are present and in the proper format and if not, reprompt for them or reformat them as 
necessary to proper form. 

2) Social Security Check . The input social security number is compared with one 
or more published social security number tables or processed using one or more algorithms to' 
determine its validity. These tables may include such information as numbers reported as 
deceased or fraudulent. 

3) Address and Telephone Checks . The address and telephone number provided 
are verified for consistency (i.e., city, state, and zip code agree; area code agrees with state) 
and the user’s address is standardized. Standardization allows for more accurate matching 
with other databases at later stages of authentication process 10. During the preprocessing 
step 26, rejection or flagging for additional authentication may occur as a result of 
mismatches. 

4) Driver’s License Validation Check . The input driver’s license number is 
processed to verify that the number is valid for the state of issue. These algorithms may be 
obtained through departments of motor vehicles or otherwise. 

The following information is preferably prompted for (R being required, O being 
optional) by authentication process 10 during preprocessing step 26 and supplied by the user: 


Table 1 


DESCRIPTION 
Last Name 
First Name 
Middle Initial 
Suffix 

Maiden Name, if applicable 


REO/OPT 

R 

R 

0 

0 

0 
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Current Address (CA) 

At CA < 2 Years Indicator (Y/N) 
Former Address 

Home Phone Number 

Area Code Change Indicator (Y/N) 

Home Phone Published Indicator (Y/N) 

Work Phone Number 

Gender 

Date of Birth 

Social Security Number 

Drivers License Indicator (Y/N) 

Drivers License Number (DL) 

Drivers License State of Issue 

Mother's Maiden Name 
Year of High School Graduation 
Number of Siblings 
Email Address 


R 

R 

R only if At CA < 2 Years 
Indicator is Y, otherwise Optional 


R 

R 

R 

0 

R 

R 

R 

R 

R only if DL Indicator set to Y, 
otherwise Optional 
R only if DL Indicator set to Y, 
otherwise Optional 


0 

0 


0, includes half and step siblings 
0 


Other, non-wallet information, which is used for subsequent levels of authentication, 
can be collected during preprocessing step 26 or deferred until a later phase of the 
authentication process 10. A user failing to supply this information during preprocessing step 
26 may be reprompted for it, and processing may or may not continue in the event the user 
never supplies information designated as required. This information preferably includes: 


Table 2 


DESCRIPTION 
Name of Lender 
Loan Account Number 
Loan Type Indicator 
Monthly Payment Amount 


REO/OPT 

R, only if Second Level Authentication used 
0 , 

R, only if Second Level Authentication used 
r’ only if Second Level Authentication used 


Preprocessing step 26 may thus include a set of validation checks including standard 

field checks, social security number validation, address validation, area code validation, and 
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driver’s license validation and other preliminary data verification. It is preferable that 
preprocessing occur in the order presented, in part due to data dependencies of later checks on 
the earlier ones. However, it will be understood that the order may be rearranged, and 
different preprocessing checks may be employed. The enumerated validation checks are 
discussed in more detail in order below. 

First, standard field checks preferably occur at client 110, where and when the 
requested data is collected, to ensure that all required data is present and all provided data is 
in the proper format and meets minimum requirements. Completing this processing at client 
110 minimizes the number of requests that must be terminated at this early point in the 
authentication process due to formally incorrect data. This is particularly important when the 
user is not present at the time of authentication, such as when requests are submitted in batch 
form rather than interactively. In general, the standard field checks make sure that an 
expected range or format of characters are input by the user, appropriate to individual queries 
and data types. 

The following is preferably accomplished during standard field checks: 

1) All required fields must be present. 

2) All provided fields must be in the proper format. 

First name must have at least one letter provided. 

Phone numbers must have 10 digits. 

Social security number must have 9 digits. 

Social security number must not have all 9 digits the same. 

Social security number's first 3 digits must not be equal to 000. 

Social security number's 4 th and 5 th digits must not be equal to 00. 

Social security number’s last 4 digits must not be equal to 0000. 

3) Specified fields must meet additional requirements. 

Age, derived from date of birth, must be 18 years old or older. 

(However, a telephone number and drivers license may still be verified, 

even if a credit file is not available) 
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Email address must contain an @ sign and a “.com” or other domain. 


The user is preferably afforded up to two additional attempts to correct any fields that 
do not meet the standard field check requirements. If any field cannot be corrected after a 
total of three attempts, the authentication process 10 is preferably aborted. If the request has- 
been successfully completed as determined by the standard field check portion of 
preprocessing step 26, the request may continue to the next preprocessing check. 

At that next stage of standard field checks, the social security number may be checked 

for some or all of the following: 

Social security number contains 9 digits 

Social security number ^ 000000000, 11111111, ..., 999999999. 

Social security number first 3 digits & 000 
Social security number 4th and 5th digits ^ 00 
Social security number last 4 digits & 0000 

Social security number does not match any social security number found on 
the Social security number fraud table. 

Social security number is in the issued range as determined by a lookup on the 
social security number range table. 

Date of birth agrees with the social security number issue dates. 

The check against the published social security number fraud table is used to ensure 
that the supplied social security number is not listed as fraudulent. Such a table may be 
obtained from any of a number of sources including, for example, credit reporting companies 
or law enforcement agencies. The social security number range table is used to ensure that 
the supplied social security number is not an invalid number. Such a table may be obtained 
from any of a number of sources including^ for example, governmental agencies. 

Once it has been determined that the social security number has been issued, and a 
range of issue dates is known, the date of birth provided on the request can be compared to 
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the date range for consistency. It is thus possible to perform another check to ensure that the 
social security number is valid based upon date of birth information. 


The user is preferably given only one additional attempt to correct social security 
number information that has been rejected by social security number validation checking. If 
the social security number cannot be accepted after a total of two tries, authentication process' 
10 is preferably aborted. 

Next, the validity of address information is confirmed, preferably using an address 

correction and standardization package (such as the PostalSoft package available from First 

Logic Corp.). For current address, and former address if provided, the package may: 

Verify that the city, state and zip code agree. If only a city and state are 
provided, the package may be able to add the zip code. If only a zip code 
is provided, the package usually can add the city and state. 

Standardize the address line. The package can correct misspelled street 
names, fill in missing information and strip out unnecessary punctuation 
marks and spaces. 

Identify undeliverable addresses (i.e., vacant lots, condemned buildings, 
etc.). 

Create a status code that tells how an input address had to be corrected. 

Create an error code that tells why an input address could not be 
matched, or assigned. 

Responses, or actions, for each of the possible address-related status codes or error 

codes in error code matrix 156 (illustrated in Figs. 9-11) are provided as output during the 

preprocessing step 26. The user is preferably given only one additional attempt to correct 

each address that has been rejected by address validation. If the address cannot be corrected 

after a total of two attempts, the request proceeds as designated in the response matrix 154 

illustrated in Figs. 9-11. The response matrix 154 may be located on authentication server 

120, in authorization database 152 or elsewhere and serve to associate messages with test 
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results and transaction records during the address portion of preprocessing step 26, 
concurrently with overall application processing. 

In other words, the response matrix 154 sends messages to client 110 based upon 
specific verification tests or based upon the current status of the transaction record 1 12. For 
example, the message may prompt the user to verity that data which was input is correct or a 
message to direct the user to call customer service for manual intervention. The response 
matrix 154 is preferably parameter driven, so that appropriate messages can be associated 
with particular events. 

The area code for the home phone number is preferably checked to determine if it is 
valid for the state supplied in the current address, in preprocessing step 26. The area code and 
state provided in connection with the request are compared with an entry for the area code in 
an area code table, available from database and other sources. The area code table contains 
area code information for each of the area code locations in the geographic area being served. 

The database for the area code and associated information may be preferably 
implemented, for example, using the commercially available MetroNet package. The phone 
number database information may be stored in phone database 180 connected to 
authentication server 120, or otherwise. The consistency of area code to state of residence 
may, for instance, be checked. 

The user is preferably given only one additional attempt to correct home phone 
number information that has been rejected by the area code validation check. After the home 
phone number has been accepted or after a total of two tries, the process indicates the result, 
valid or not valid, in the transaction record 112 and proceeds. 

Next, the drivers license number is checked to ensure that the format of the number is 

consistent with the format for the state of issue. An algorithm may look up the state of issue 
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and compare the driver’s license number provided in the request with the accepted format for 
the state. The user is preferably given only one additional attempt to correct driver’s license 
number information that has been rejected by the driver’s license check (or may be 
terminated immediately, according to vendor preference). After the driver’s license number 
has been accepted or after a total of two tries, the authentication process 10 indicates the 
result, valid or not valid, in the transaction record 112 and proceeds. 

In the event the user will be paying for a product or service with a credit card, 
authentication process 10 may invoke credit card verification at this point. In this case, 
checks may be executed against a credit card database. These checks may include ensuring 
that the available credit line is sufficient to make the purchase, ensuring that the billing 
address for the credit card in the database matches the submitted address, and ensuring that 
the credit card is not stolen. Databases presenting this sort of information are commercially 
available. 

Preprocessing step 26 thus may include internal corrections as well as comparisons of 
user-supplied data to known data which may be obtained from separate sources. Those 
sources may be third party databases such as commercial or government databases, or internal 
databases. Preferably, however, preprocessing step 26 is limited to checking user-supplied 
data against wallet-type data which is relatively conveniently, and locally, accessed. 
Preprocessing step 26 consequently offers increased certainty of authentication by using 
additional databases and requiring internal consistency as a predicate to first and second level 
authentication. 

In conjunction with the checks carried out by preprocessing step 26, credit database 

160 may be any suitable consumer credit history database available from various sources 

including credit reporting companies such as Equifax™. Mail database 170 and phone 
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database 180 may be any suitable databases providing address and telephone information for 
the relevant geographic area (e.g., MetroMail which is a compendium of regional Bell 
operating company-supplied information). Other databases 190 may include, for example, a 
check services drivers license database which provides information concerning check 
validity. Any commercially available or internal database or others may be employed in 
processing the verification substeps of the preprocessing step 26. 

Additionally, the checks of preprocessing step 26 may include the use of a credit card 
application fraud model, or some other model which statistically analyzes response data. For 
example, the data supplied by the user may be modeled and graded for confidence level based 
upon empirical models supplied by third party vendors or available internally. An illustration 
of pattern recognition criteria that may be employed in this regard by the invention is 
illustrated in Figs. 17 and 18. As illustrated in those figures, in general the invention 
monitors user input recorded in transaction record 112 or otherwise for repetitive attempts at 
authentication, which may represent attempted fraud or some type of network attack. 

In such instances, and as illustrated in pattern recognition criteria matrix 904 shown in 
Fig. 17, the input may include valid portions of information such as a social security number 
but varying unsuccessful attempts to find valid input for other fields. At any time during 
authentication process 1 0, the invention may preempt the authentication event and terminate 
the session when pattern recognition senses a significant probability of irregularity. Different 
responses to different types of detected potential fraudulent transactions are shown in the 
pattern recognition match action matrix 912 of Fig. 19. As illustrated in the figure, different 
types of inconsistencies may result in different actions, including the locking out of suspected 
fraudulent entries for such patterns as the same name under varying email addresses. Other 
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inconsistencies may result in the starting of the authentication process 10 over again (QILT 
entries) at user request. 

In a preferred embodiment of the invention, the data supplied by the user must match 
a record from at least two data sources to graduate from the preprocessing step 26. This 
increases the level of certainty that the user’s identity is genuine before graduating from that 
stage. Matching routines, implemented for each data source and type of check, compare 
query data to known source data and preferably assign a value to every match instance. This 
value may be termed an authenticity certainty score. An authenticity certainty score may be 
accumulated based upon the collective values assigned for each match instance of 
preprocessing step 26. The authenticity certainty score may be employed and compared 
against predetermined thresholds to determine the next action for the request (i.e., approve, 
approve with restrictions, deny, go to first or other level preprocessing). 

If the data provided by the user does not meet the requirements of some or all of the 
checks of preprocessing step 26, a message may be returned to the user via link 150 
requesting the data in question be corrected and resubmitted. Upon resubmission, the input 
data will again be analyzed. Alternatively, authentication process 1 0 may be preconfigured to 
immediately reject a request based upon a failure to satisfy a minimum level during 
preprocessing step 26. 

If the request is identified as a result of the association check 24 or other analysis as 
possibly fraudulent using the association check or otherwise, a message may be returned to 
client 110 indicating that the request cannot be processed automatically and that manual 
processing such as calling customer service is necessary. 

Biometric data may be employed either alone or in combination with the above 

preprocessing as well as subsequent authentication levels to ensure the identity of a user. 
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That biometric data may include, for example, fingerprint information from the user, captured 
in analog or digital form, for instance, via an imprint peripheral connected to client 110. 
Biometric data may also include infrared or other retinal or iris scans, or finger or hand 
geometry matches. Likewise, biometric data used by the invention may also include 
handwriting recognition, voice recognition using digitized sampling or other means or facial ' 
recognition input from video or other devices. 

The biometric data may also include DNA database matching. In general, any 
biometric technology now existing or developed in the future may be incorporated in the 
invention. The biometric data may be used as input fields or records in the preprocessing, 
first or second authentication level stages. Alternatively, biometric data may be used as a key 
to unlock and release a digital certificate 902 issued to the user, to be stored on client 1 10 or 
otherwise. 

Fig. 1 is a flowchart illustrating the overall authentication process according to the 
invention. Authentication process 10 starts at step 12. The authentication process 10 
prompts a user for first level information at step 14. Again, the first type of information is 
preferably wallet-type information, that is, information such as name, address, driver’s license 
or other information commonly carried on the person. The user inputs that first level 
information via a keyboard, mouse, voice digitizer or other suitable input mechanism at 
step 16. Step 18 identifies that the user has completed first level information input. Step 
20 transmits the input. The transaction record 112 is initialized at step 22. 

Step 24 performs an association check on the information input by the user. 
Authentication process 10 may then invoke the preprocessing step 26 discussed above. If 
preprocessing step 26 is included, step 28 may also be provided, which determines whether 

preprocessing step 26 is complete. If preprocessing step 26 is not complete, authentication 

- 23 - 


process 10 may return to step 14 to prompt the user for omitted, corrected or additional 
information, return to step 16 to allow the user to input information, or end authentication 
process at step 30. If preprocessing step 26 is complete, authentication process 10 
proceeds to step 32 of first level authentication. 

Authentication process 10 matches, at step 32, the first type of information input by 
the user with information received from one or more separate data sources. Based on that 
comparison, authentication process 10 determines whether the first level authentication is 
complete at step’ 34. If the first level authentication is not complete, authentication process 
10 may return to step 14 to prompt the user for omitted, corrected or additional 
information, return to step 16 to allow the user to input information, or end authentication 
process at step 36. 

If the first level authentication is complete, authentication process 10 determines at 
step 38 whether the user should be authenticated. If the user has not been rejected outright 
but has not yet been authenticated, authentication process 10 proceeds to step 40, second 
level authentication. Step 40 request and tests the user’s input of a second type of 
information, which is preferably non- wallet type information. 

Authentication process 10 determines whether a request for information has been 
repeated more than a predetermined number of times at step 42. If the attempt exceeds the 
predetermined limit, authentication process 10 ends at step 44. If the attempt does not 
exceed the predetermined limit, authentication process 10 determines whether step 40 is 
complete at step 46. If step 40 is complete, authentication process 10 renders an 
authentication decision at step 48, then ends at step 50. If step 40 is not complete, 
authentication process may return to step 38 or end at step 47. 
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Fig. 2 is a flowchart illustrating the process of the first level authentication step 32 
in more detail. First level authentication process 32 initiates at first level comparing step 
52. The first level comparing step 52 compares the information input by the user with 
information about the user retrieved from one or more known data sources. The user may 
be queried in the first level authentication step 32 for similar information to that accepted 
during the preprocessing step 26, or for refined or additional information. During 
processing of any user-input phone number information in the first level authentication step 
32 after preprocessing step 26 (but preferably not in preprocessing step 26 itself), if the user 
indicates that they have been at the home telephone number for less than four months, the 
home telephone number and related source information may be preferably further checked 
against an electronic directory assistance source, for better currency as compared to an offline 
database. During processing of any user-input driver’s license information in the first level 
authentication step 32 (but preferably not in preprocessing step 26), any further checks 
against the driver’s license database may be preferably implemented, for example, using the 
commercially available ChoicePoint drivers license database. Information from that external 
database is generally derived from official department of motor vehicle records or insurance 
claims information, the content of which may vary by state of issue. Step 54 assigns values 
and priorities to each response input by the user. Information that is of greater significance 
may be assigned a higher value or priority. 

The transaction record 112 (illustrated in Figs. 13-16) initialized in step 22 is used 

throughout the authentication process 10 to keep track of user input and authentication 

results. After the appropriate queries have been processed and all results stored in the 

transaction record 112, the transaction record 112 is used to determine an authentication 

score with respect to the request. Step 56 calculates the total authentication score, and 
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optionally, a score for each data source, data field, etc. The results are categorized as a 
big hit (B), a regular hit (R), a possible hit (P), or no hit (N) depending on results. Those 
results may then be combined with the results of second level authentication process 40 to 
determine an overall authenticity certainty score, as illustrated in Figs. 23-28 and discussed 
below. 

Authentication process 10 determines whether one or more of the authentication 
scores is greater than or equal to a predetermined authentication value or threshold at step 
58. If the authentication scores are greater than or equal to the predetermined 
authentication value, authentication process 10 renders an authentication decision at step 60 
and then ends at step 62. 

If one or more of the scores are less than their corresponding predetermined 
authentication value, authentication process 10 determines whether the level of certainty 
meets a predetermined certainty level at step 64. If the level of certainty is below the 
predetermined certainty level, authentication process 10 ends at step 66. Otherwise, 
authentication process 10 determines whether corrected or additional first type information 
is needed at step 68. If no other information is needed, authentication proceeds to step 40, 
second level authentication. If user input information needs to be revised, authentication 

process 10 may return to step 14 or step 16. 

Figs. 31-33 illustrate a set of queries associated with preprocessing step 26 and first 
level authentication 32 in an example authentication session according to the invention. As 
can be seen in the figures, these phases of the invention query for and process wallet-type 
information to reach a first level of confidence about the genuineness of the user’s identity. 

Fig. 3 is a flowchart illustrating the second level authentication process 40 in more 

detail. Second level authentication process 40 begins with step 310. Step 310 accesses 
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available second type information from data sources, such as a credit file. Step 312 
prompts the user for second type information from within that determined to be available in 
step 310. Step 314 determines whether the user input matches the accessed information. 

In the execution of second level authentication process 40, authentication server 120 
may access credit database 160. Credit database 160 may be preferably implemented, for 
example, using a commercially available Equifax™ consumer credit file, in the ACRO file 
format. 

Inquiries may be transmitted back and forth between application server 130 and 
authentication server 120 during second level authentication process, using the System-to- 
System 93 (STS) inquiry format for these types of data files, as will be appreciated by 
persons skilled in the art. Credit line information returned from credit database 160 may 
be in System-to-System file fixed format (FFF), consistent with the ACRO file 
configuration. Second level authentication process 40 executes the search against credit 
database 160 to match the user’s input against data in that file. 

The search maybe carried out according to the ACRO L90 search format, with 
results again categorized as a big hit (B), a regular hit (R), a possible hit (P), or no hit (N) 
depending on results, which in one embodiment are returned to authentication server 120 
starting in ACRO header segment position 285 in a 13 bye segment. Matches or no 
matches are returned as logical flags within that header segment. 

If the information matches, authentication process 10 either provides a higher 
degree authentication in step 316 or issues another degree of authentication in step 318. If 
the information does not match, authentication process 10 may issue a lower degree 
authentication, return to step 312 or end at step 324. 
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An example of point scoring used in second level authentication according to the 
invention is illustrated in Figs. 20 and 21. The scoring matrix 906 of Fig. 20 includes a 
set of point values for point values related to trade line accounts which the user may have, 
on a sliding scale according to the relative degree of significance of various accounts. In 
general, and as indicated in the relative weight matrix of Fig. 21, the proper identification 
of a lender name is given greater weight compared to monthly payment amount or terms of 
account data. 

In Fig. 22, the resulting certainty scores are ranked according to four categories of 
big hit (B), regular hit (R), probable hit (P), and no hit (N). Different combinations of 
accounts may lead to different maximum scores, according to the reliability or significance 
of the accounts available for second level authentication step 40. 

Upon completion of both the first level authentication step 32 and second level 
authentication step 40, results of all checking may be assembled to determine an overall 
authenticity certainty score, values for which are illustrated in the overall certainty scoring 
matrix 918 of Figs. 23-28. In general in those figures, big hits on credit file (second level 
authentication) checks contribute to higher overall certainty scores, which are normalized 
to 0 to 100. However, preferably no single check qualifies or disqualifies a user from 
authentication. 

Rather, according to the invention the aggregate weighting of all the user’s response 
is factored into a variety of possible score ranges, depending on how highly the information 
they supplied correlates to the entire collection of data sources used by the invention. The 
scoring levels may be aggregated as shown in the assignment matrix 920 of Fig. 29 to 
develop a tiered categorization (B, R, P, N) for all levels of authentication, and generate 

responses according to threshold table 922 as illustrated in Fig. 30. While particular 
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numerical levels are shown in those matrices, it will be appreciated that the different scores 
and tiers are selectable or scalable according to application needs, in the invention. 

Figs. 34-36 illustrate a set of queries in screen shot form associated with second 
level authentication step 40 in an example authentication session according to the invention. 
In general, at this stage the authentication process 10 identifies and accesses trade (credit) 
line information to query for data of a specific and private nature, which enhances the 
security profile of the user. In the example shown, both credit and merchant or trade line 
accounts are queried for lender identity and amounts. ‘ Accurate identification results in 
authentication, followed by issuance of a digital certificate 902 as desired. 

The system and method of the invention are customizable to allow a vendor operating 
an authenticating server 120 to set various parameters, including the thresholds or 
predetermined levels at different points of authentication process 10. If the predetermined 
authentication or certainty level has not been reached for a particular data source or data field, 
the user may not be eligible for authentication, or a higher degree of authentication. 

If a user successfully completes preprocessing, first and second authentication, in one 
embodiment the invention may issue a digital certificate 902 to the user, as illustrated in Figs. 
37-41. As illustrated in Figs. 37-40, after an indication of successful authentication the user 
is directed to input identification and challenge or password information to generate and store 
digital certificate 902. The digital certificate 902 contains a set of fields including user 
identification, a digital certificate serial number, an expiration period, as well as information 
related to the issuer of the digital certificate and fingerprint data for the digital certificate. 

The digital certificate 902 may be preferably stored in secure fashion on client 1 10, 
that is, protected by user identification and challenge or password queries before the recipient 

can release the digital certificate 902 for further transactions, as illustrated in Figs. 37 and 38. 
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Digital certificate 902 may be a data file stored in common machine readable format that 
upon proper release by the user can be presented to other authentication servers for later 
transactions, as evidence of identity and avoiding the need to reauthenticate the user for later 
events. As illustrated, digital certificate 902 contains an expiration field, but the certificate 
can be generated to persist indefinitely. 

Digital certificate 902 may be updated using a full or abbreviated authentication 
process 10 according to the invention, according to the grade of security required for 
particular future transactions. For example, a digital certificate 902 may be issued recording 
a medium grade of confidence of the user’s identity, but to execute a sensitive transaction, the 
user may need to update and upgrade the digital certificate 902 to perform that later 
transaction. 

Although illustrated with two levels of authentication processing, it will be 
understood that the invention contemplates three or more levels of authentication performing 
additional checks using additional databases or prompting the user for more information, 
when appropriate to transaction requirements. Any of the levels of the authentication process 
10 may be implemented via an interactive query format, e.g., using a multiple choice check- 
off box. At no time during presentation of the interactive query is the user presented with 
potential answers revealing only correct information, so that identification information cannot 
be captured simply by entering authentication process 10. Moreover, in the implementation 
of the invention it is possible to follow the entire authentication process 10 with a consumer 
profiling step, in which the now-authenticated user identity is associated with purchase, 
travel, geographic and other information to enable more highly targeted marketing or 


transaction activity. 
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In general, in the execution of the authentication process 1 0 of the invention, answers 
to the interactive query questions are given highest relative weighting, followed by 
authentication checks against a user’s credit file, followed by telephone information and then 
driver’s license information. 

As shown in Fig. 4 and described above, the preprocessing step 26 may be conducted • 
before the hierarchy of authentication levels and include several preliminary procedures, 
mainly designed to ensure consistency in format. Discussion will return to preprocessing 
step 26 to describe the preprocessing stage in more detail in conjunction with Figs. 5-8. It 
will be understood that various combinations of standardization 400, formatting verification 
410, verifying consistency 420, and verifying data validity 430 may be incorporated into the 
preprocessing step 26. As illustrated in Fig. 1, after preprocessing step 26 is executed a 
decision 28 is made whether authentication should proceed. The decision 28 may result in a 
return to initial step 14 or an end to the automated authentication process 10 at step 30. 

If preprocessing step 26 includes a formatting verification 41 0, the following process 
may be followed. The user input data is checked at step 500 to determine that it is properly 
formatted. For example, the data may be checked to verify that the required fields have been 
entered (e.g., user name) or that the proper number of characters have been entered (e.g., nine 
digits for a social security number). If the result of the decision step 500 is that the data is not 
in the proper form, a determination is made at step 510 whether the user has been prompted 
for this information previously. 

The authentication process 10 may be configured to allow a predetermined number of 

chances for the user to input data in the correct format. If the number of attempts exceeds the 

predetermined number, the process may terminate at step 520. If the predetermined number 
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of chances has not been exceeded, the user may be prompted to input the data in the correct 
format at step 530. If the data is in the correct format, the process proceeds to step 540. 

Fig. 6 depicts the process for standardization 400 of the data. At step 600 a 
determination is made whether the data is in the proper standard form. For example, the 
user’s postal address may be checked for misspelled street names, or unnecessary 
punctuation. If the determination 600 finds the data to be non-standard, a determination 610 
is made whether the non-standard data can be corrected. If the data can be corrected, it may 
be accomplished at step 620 by internal or other processes. If the data cannot be corrected, a 
determination is made at step 630 whether the user has been prompted for this information 
previously. 

The authentication process may be configured to allow a predetermined number of 
chances for the user to input data in the correct format. If the number of attempts exceeds the 
predetermined number, the process may terminate at step 640. If the predetermined number 
of chances has not been exceeded, the user may be prompted to input standard data at step 
650. If the data is in standard form, the process proceeds to the step 660. 

Fig. 7 depicts the process for determining the validity 430 of the data. For example, 
the validity may be verified by determining at step 700 whether the data is valid (e.g., does 
the social security number match any social security number found on the published deceased 
or fraudulent table). If the determination is made that the data is invalid, a determination 710 
is made at step 710 whether the user has been prompted for this information previously. If 
the number of attempts exceeds the predetermined number, the process may update the 
transaction record at step 720 to reflect the presence of the invalid data. 

After the transaction record 1 12 is updated in step 720, an additional determination is 

made at step 730 of whether the process can proceed with this invalid data. If not, the process 
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may terminate at step 740. If it can, the process may proceed to step 750. If the 
predetermined number of chances has not been exceeded, the user may be prompted to input 
valid data at step 760. If the data is valid, the process proceeds to step 750. 

A similar process may be followed to determine whether the data is consistent at step 
420, as illustrated in Fig. 8. In step 760, the determination is made whether the data from' 
separate field entries are consistent. For example, data may be checked to verify that the area 
code entered matches the zip code entered. If the determination is made that the data entered 
by the user is not consistent, a determination is made at step 770 whether the user has been 
prompted for this information previously. If the number of attempts exceeds the 
predetermined number, the process may update the transaction record 112 in step 780 to 
reflect the presence of the inconsistent data. 

After the transaction record 1 12 is updated 780, an additional determination is made at 
step 790 of whether the process can proceed with this inconsistent data. If not, the process 
may terminate at step 800. If it can, the process may proceed to step 810. If the 
predetermined number of chances has not been exceeded, the user may be prompted to input 
valid data at step 820. If the data is valid, the process proceeds to step 810 and the next 
preprocessing check. 

Figs. 9-11 show an example of the use of a matrix to verify address information in 
processing validity 430 or consistency 420. As shown, the verification process, which may 
be implemented using the commercially available PostalSoft, generates a matrix of address 
values to determine certain address information. Fig. 10 shows an example of certain error 
codes which may be generated to prompt user responses according to PostalSoft format when 
entered values, such as zip code, are not in proper format. Fig. 11 shows an example of 
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certain actions and messages according to other types of data entered during processing for 
consistency 420. 

Generally speaking, there are several ways to administer the queries at the various 
levels of authentication of the invention, depending upon the requirements of the transaction. 
If the user is available at the time of application for an interactive dialog (eg., Internet' 
request), a multiple choice questionnaire is preferably dynamically created by authentication 
process 10 and presented to the user, through client 110, for completion. 

Multiple choice alternatives for each question are preferably selected based upon the 
regional biases of the user, if applicable, and are designed to make it difficult for a fraudulent 
applicant to correctly guess the answers. That is, potential selections for various credit line or 
merchant account providers are provided in the same general geographic region as the user s 
home address, so that credit line account vendors are not obviously wrong based on location. 
The user points and clicks on their selections, or provides answers in some other suitable 
way. The user-supplied answers are then returned to authentication process 10 by client 110 
for automated evaluation. 

If the user is not present at the time of application (e.g., batch submission), the 
information required to administer validation is provided on the initial application. If the user 
supplies account numbers, second level authentication step 40 will attempt to make the 
comparisons automatically. However, if the comparisons cannot be made automatically or 
the account numbers are not provided, the comparisons may be accomplished manually 
through human intervention. The results are returned to second level authentication step 40 
for final evaluation. 

Fig. 18 illustrates an example authentication carried out according to authentication 

process 10 of the invention. In general, as illustrated in that figure, the user presents name, 
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social security number, date of birth, email and mailing address information, followed by 
home telephone number and driver’s license data. That information is accepted and 
processed through preprocessing step 26 and first level authentication step 32, after which it 
is determined that the data are consistent and merit proceeding to second level authentication 
step 40. 

In second level authentication step 40, a sequence of questions are presented in an 
interactive query directed to mortgage account information, requesting lender and amount 
inf or ma tion followed by other merchant account information. Following successful 
authentication, the user is asked whether they wish to generate digital certificate 902, which 
is generated recording the successful authentication and protecting the digital certificate 902 
by way of identification and challenge question data. 

Any or all of the processing steps described above can be invoked selectively or 
rearranged to constitute a complete authentication process 10. The requirements of the 
transaction will determine which processes to combine for particular authentication needs. It 
is possible to configure several different implementations as standard offerings. The party 
employing the authentication system (vendor) can either use these standard offerings, or 
customize a configuration to their needs. With any implementation, the invention allows 
flexibility in determining certainty of authenticity, either through process configuration or 
setting certainty thresholds. 

In the practice of the invention, in the event of temporary downtime or other 
unavailability of any of the data sources used for comparison, the invention may revert to a 
backup source for that particular type of information (which may be generally consistent but 
not as current), substitute another data source, or take other action. 
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Fig. 42 illustrates an offline remote authentication embodiment of the invention, in 
which some processing including delivery of a validated ID is conducted using ordinary mail. 
As illustrated in Fig. 42, in this embodiment, a remote authentication system 1002 controls 
two processing objects, a remote authentication object with a social security number field 
1004, and a remote authentication object without a social security number field 1006. The- 
remote authentication system 1002 invokes the remote authentication object 1004 when a 
user has presented a social security number, in an online application for a credit or other 
transaction. The remote authentication object 1004 may invoke the preprocessing step 26, to 
process standard field checks as in the other embodiments above. In this embodiment, in part 
because of the requirements for mail delivery, failure of one or more data fields for address 
standardization, such as zip code errors, blank fields, foreign addresses, and undeliverables 
may result in a failure state 1018. The failure state 1018 may also be reached when age is 
less than a predetermined level, or standard social security checks as described above are not 
met. Other factors which may result in a failure state 1018 include mix matches concerning 
telephone numbers, social security numbers and fraud victim indicators present in a credit 
file. 

If the remote authentication object 1004 determines that the user has achieved a 
sufficient score during preprocessing step 26 and any further processing steps, the pass state 
1008 may be reached. Online issuance of a digital certificate 902 or other authentication may 
ensue. However, if the remote authentication object 1004 determines that the user’s score lies 
between those designated for a pass state 1008 and a failure state 1018, the remote 
authentication object may offer an offline authentication state 1010, in which verification is 
transmitted using regular mail. 
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In this condition, offline authentication state 1010 invokes mailability filter 1012, 
which tests for matches on first initial, last name, a house number and zip code from at least 
one address database, as well as consistency of age and year of birth and a social security 
number which is either valid or shows no more than a small number of digit transpositions. 
Other criteria may be applied. If a sufficient score is reached in the mailability filter 1012' 
processing, a mail state 1014 is reached in which the entered addressing information is used 
to transmit a PIN or other identification information to the user via regular mail. If a 
sufficient score is not reached in the mailability filter 1012, a failure state 1016 is reached, no 
verification is sent by mail and processing terminates. 

If a user fails to supply a social security number, as illustrated in Fig. 42 control is 
passed to remote authentication object 1006, which may apply the preprocessing step 26 and 
further steps to test inputted user information. If the inputted user information does not reach 
a predetermined threshold, control passes to a failure state 1022. If a sufficient authentication 
score is reached, processing proceeds to offline authentication object 1020. Offline 
authentication object 1020 invokes mailability filter 1024 which processes the user-supplied 
input without a social security number to determine whether address standardization, age- 
related, address-related, or fraud flags are present. If a sufficient authentication score is 
reached in mailability filter 1024, control passes to the mail state 1026, in which a valid 
identification PIN is transmitted to the user at the entered address using regular mail. 
Conversely, if mailability filter 1024 is not satisfied, a failure state 1028 is reached in which 
no material is mailed and processing terminates. 

An embodiment of the remote authentication system 1002 is illustrated in more detail 

in Fig. 43, in which a social security supply object 1030 tests whether the user is capable of 

providing a social security number field. If the user is capable of providing a social security 
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number field, control proceeds to pass test module 1032, which may perform preprocessing 
step 26, first level authentication step 32, second level authentication step 40 or other 
processing. If the user passes those levels of authentication with a sufficient score, control 
passes to an earned icon state 1034, providing the user with an online authentication icon, 
digital certificate 902 or other issued verification. 

If the pass test module 1032 is not passed, a fatal error object 1036 may test for fatal 
errors in social security, address, age-related or other desired data fields. If fatal error object 
1036 does not detect a fatal error, control passes to a mailability filter 1038 which tests for 
mailability using zip code and state, name, deliverability and other field checks, after which a 
mail state 1040 is entered if the user has successfully established reliable information. After 
mail state 1040 is entered, both the PIN may be mailed via regular mail and a user icon issued 
in earned icon state 1042. Conversely, if either the fatal error object 1036 or mailability filter 
1038 are not satisfied with the information the user has entered, a failure state 1044 is 
entered, and processing ends without transmitting an ID via mail or an icon being issued. 

As illustrated in Fig. 44, alternatively if the user is not capable of supplying a social 
security number to social security test object 1030, then control passes to fatal error object 
1046. If no fatal error is detected by fatal error object 1046, control is passed to mailability 
filter 1048, which tests for deliverable mailing information, as above. If mailability filter 
1048 is satisfied, the mail state 1050 is reached in which a regular PIN identification is 
mailed via mail to the user, after which an earned icon state 1052 is reached, issuing the user 
an online icon identification. Conversely, if either the fatal error object 1046 or mailability 
filter 1048 are not satisfied, a failure state 1054 is reached, and processing ends. 

The foregoing description of the authentication system and method of the invention is 
illustrative, and variations in construction and implementation will occur to persons skilled in 
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the art. For instance, while the invention has been generally described as involving a single 
user supplying authentication information in a single interactive session or alternatively in 
batch mode, both queries and user input may be provided at different times using different 
input modes, when the transaction allows. This may be the case for instance when the 
transaction involves setting up an online subscription to publications or services. 

For further example, while the invention has been described in a client/server 
environment in which a user initiates a transaction using a personal computer or other device 
over a computer network, the user could initiate the transaction over other networks. The 
user for instance could conduct a transaction using a cellular telephone equipped with an 
alphanumeric display which permits the user to keypad data in over the mobile cellular 
network. 

For yet further example, while the invention has been illustrated in terms of an 
individual consumer initiating a network transaction, the invention can also verify the identity 
of other entities such as corporations, schools, government units and others seeking to 
transact business over a network. Those entities can be international in nature. The scope of 
the invention is accordingly intended to be limited only by the following claims. 
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